home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 2742 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.2 KB
  1. Path: prairienet.org!sjmccaug
  2. From: sjmccaug@prairienet.org (Scott J. McCaughrin)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Why are 32 bit better than 16 bit pgms?
  5. Date: 19 Jan 1996 12:50:10 GMT
  6. Organization: University of Illinois at Urbana
  7. Message-ID: <4do422$jj1@vixen.cso.uiuc.edu>
  8. References: <4dniuk$lms@dragon.solect.com> <30FBFFE6.1FEB@netcom.com>
  9. Reply-To: sjmccaug@prairienet.org (Scott J. McCaughrin)
  10. NNTP-Posting-Host: firefly.prairienet.org
  11.  
  12.  
  13. In a previous article, gallantm@kanservu.ca (Matt Gallant) says:
  14.  
  15. >In article <30FBFFE6.1FEB@netcom.com>, vain@netcom.com says...
  16. >>
  17. >>I have a simple questions:
  18. >>
  19. >>   What's are 32 bit pgms better than 16 bit programs?
  20. >>
  21. >>   Thanks!
  22. >
  23. >The answer to this question can be a matter of opinion.  The common answers 
  24. >given are:
  25. >
  26. >1. For developers, programming becomes easier because you no longer have to 
  27. >worry about memory segmentation.  Because of this, data structures and blocks 
  28. >are no longer limited to 64K.  No more segment:offset addressing.  Your 
  29. >program can "pretend" that memory is a "flat" range, and just use 32-bit pointers 
  30. >ranging from byte 0 through 4GB.  (Of course, not all of this memory area is valid 
  31. >to the process without making the proper memory allocations)
  32. >
  33.  
  34.  But with "huge" memory model permits the 64K limit to be exceeded in the
  35.  real-mode model, and not everyone considers segmented memory a constraint.
  36.  
  37. >2. 32-bit programs are pre-emptively multitasked.  A 32-bit application can no 
  38. >longer hog the process by not yielding on a timely basis.  (There is one snag to 
  39. >this scheme if you're running on Windows 95, and if you develop for Windows 95 
  40. >you are sure to hear about it.  This "snag" is refered to as the Win16Lock or 
  41. >Win16Mutex.)
  42.  
  43.  This is more a feature of Win95 than the memory model -- besides, there are
  44.  advantages to non-preemptive multitasking. Also, consider CDOS and Concurrent
  45.  PC-DOS.
  46.  
  47. >
  48. >3. 32-bit programs are (to a large extent) portable.  If written correctly, one set 
  49. >of source files can be compiled and run on Windows 95 and Windows NT, as well 
  50. >as being compiled for other non-Intel x86 platforms (i.e.  Alpha processors).
  51.  
  52.  I believe Win95 supports 16-bit code for backward compatibility as well.
  53.  
  54. >
  55. >4. Also, consider that as new APIs are developed (by Microsoft and 3rd parties) 
  56. >that they will probably only be ported to the Win32 platforms.  For example, I 
  57. >was just reading an Microsoft Systems Journal article about their new Speech API. 
  58. > I'm not sure that it's necessarily 32-bit only, but obviously, something as 
  59. >processing-intensive as speech synthesis and speech recognition will benefit from 
  60. >32-bits.
  61. >
  62. >5. Last, but definitely not least, 32-bit programs are allowed to have multiple 
  63. >threads of execution.  This allows you to easily create and execute routines "in the 
  64. >background" just by creating a new thread.  You no longer have to set up your 
  65. >different tasks to be done and come up with ways of switching between them 
  66. >yourself, just create a new thread, and Win32 platforms will schedule your 
  67. >background tasks themselves.
  68. >
  69.  So what? This is the standard for OS/2 as well, which is designed to run in
  70.  '286 protected-mode (only 24-bit addressing, not 32-bit). Again, this is more
  71.  a feature of the operating system than the memory model.
  72.  
  73.  -- Scott McC.
  74.  
  75.